بوابة واجهة برمجة تطبيقات بايثون: تنفيذ شبكة الخدمات للهياكل المعمارية الحديثة

في المشهد الرقمي سريع التطور اليوم، أصبحت الهياكل المعمارية للخدمات المصغرة هي القاعدة لبناء تطبيقات قابلة للتطوير ومرنة وسهلة الصيانة. وفي قلب هذه الهياكل تكمن الحاجة إلى اتصال فعال وآمن بين الخدمات. وهنا يأتي دور بوابات واجهات برمجة التطبيقات (API Gateways) وشبكات الخدمات (Service Meshes). يستكشف هذا المقال كيفية بناء بوابة واجهة برمجة تطبيقات قائمة على بايثون ودمجها مع شبكة خدمات، مما يوفر حلاً قويًا لإدارة اتصال الخدمات المصغرة في سياق عالمي.

فهم بوابات واجهات برمجة التطبيقات وشبكات الخدمات

ما هي بوابة واجهة برمجة التطبيقات (API Gateway)؟

تعمل بوابة واجهة برمجة التطبيقات كنقطة دخول واحدة لجميع طلبات العملاء إلى الواجهة الخلفية للخدمات المصغرة. وتتولى مهام مثل:

• التوجيه: توجيه الطلبات إلى الخدمة المصغرة المناسبة.
• المصادقة والتفويض: التحقق من هوية العميل والتأكد من أن لديهم الأذونات اللازمة.
• تحديد المعدل (Rate Limiting): منع إساءة الاستخدام وضمان الاستخدام العادل للخدمات.
• تحويل الطلبات: تعديل الطلبات قبل إرسالها إلى الواجهة الخلفية.
• تجميع الاستجابات: دمج الاستجابات من عدة خدمات مصغرة في استجابة واحدة.
• التخزين المؤقت (Caching): تقليل زمن الوصول وتحسين الأداء.

فكر فيها كموظف استقبال متطور لتطبيقك، يتعامل مع كل حركة المرور الواردة ويضمن وصولها إلى المكان الصحيح بأمان وكفاءة. على سبيل المثال، قد يرسل تطبيق جوال في أستراليا طلبًا إلى بوابة API، التي تقوم بعد ذلك بتوجيهه إلى خدمة تسعير موجودة في سنغافورة وخدمة مخزون في ألمانيا، وتجميع النتائج قبل إعادتها إلى المستخدم.

ما هي شبكة الخدمات (Service Mesh)؟

شبكة الخدمات هي طبقة بنية تحتية تتعامل مع الاتصال بين خدمة وأخرى داخل بنية الخدمات المصغرة. وتوفر ميزات مثل:

• اكتشاف الخدمات: تحديد موقع مثيلات الخدمة المتاحة تلقائيًا.
• إدارة حركة المرور: التحكم في تدفق حركة المرور بين الخدمات، بما في ذلك موازنة التحميل والتوجيه وكسر الدائرة.
• المراقبة (Observability): توفير رؤى حول أداء وصحة الخدمات.
• الأمان: تشفير الاتصال بين الخدمات وفرض سياسات الأمان.

تتكون شبكة الخدمات عادةً من مستوى تحكم (مثل Istio) ومستوى بيانات (مثل Envoy). يعترض مستوى البيانات جميع الاتصالات بين الخدمات ويطبق السياسات المحددة بواسطة مستوى التحكم. تخيل شبكة من السعاة غير المرئيين يتعاملون مع جميع الاتصالات الداخلية، ويضمنون تسليم الرسائل بشكل آمن وموثوق وفعال. تُمكّن شبكة الخدمات من بناء شبكات انعدام الثقة (zero-trust networking) بشكل افتراضي - حيث تقوم كل خدمة بمصادقة كل خدمة أخرى، بغض النظر عن مكان وجودها. وهذا أمر بالغ الأهمية بشكل خاص في الشركات متعددة الجنسيات التي تنتشر خدماتها عبر مناطق جغرافية مختلفة.

لماذا نجمع بين بوابة API وشبكة الخدمات؟

بينما تعالج كل من بوابات API وشبكات الخدمات اتصال الخدمات المصغرة، فإنهما تعملان في طبقات مختلفة وتحلان مشكلات مختلفة. تركز بوابة API على إدارة حركة المرور الخارجية، بينما تركز شبكة الخدمات على إدارة حركة المرور الداخلية. يوفر الجمع بين الاثنين حلاً شاملاً لتأمين وإدارة ومراقبة اتصال الخدمات المصغرة داخل وخارج المجموعة (cluster).

على سبيل المثال، لنأخذ منصة تجارة إلكترونية. تتعامل بوابة API مع الطلبات من تطبيقات الويب والجوال، وتقوم بمصادقة المستخدمين، وتطبيق حدود المعدل، وتوجيه الطلبات إلى خدمات الواجهة الخلفية المناسبة. تدير شبكة الخدمات الاتصال بين خدمات الواجهة الخلفية، مما يضمن اتصالًا آمنًا وموثوقًا بين خدمة كتالوج المنتجات وخدمة إدارة الطلبات وخدمة معالجة الدفع. قد تستخدم بوابة API خدمات مصادقة خارجية، مثل Okta أو Auth0، بينما تضمن شبكة الخدمات اتصالًا آمنًا بين الخدمات الداخلية باستخدام TLS المتبادل (mTLS).

بناء بوابة API باستخدام بايثون

تُعد بايثون، بفضل نظامها البيئي الغني بالمكتبات وأطر العمل، خيارًا ممتازًا لبناء بوابات API. سنستخدم مجموعة من أطر العمل لإنشاء بوابة قابلة للتطوير والصيانة.

اختيار أطر العمل

• FastAPI: إطار عمل ويب حديث وعالي الأداء لبناء واجهات برمجة التطبيقات. يوفر FastAPI التحقق التلقائي من صحة البيانات، التسلسل، وتوليد التوثيق.
• Uvicorn: خادم ASGI لتشغيل تطبيقات بايثون غير المتزامنة.
• Requests: مكتبة لعمل طلبات HTTP إلى خدمات الواجهة الخلفية. للسيناريوهات الأكثر تعقيدًا، فكر في استخدام `httpx` الذي يوفر دعمًا غير متزامن.
• PyJWT: مكتبة للعمل مع JSON Web Tokens (JWTs) للمصادقة.

هيكل المشروع

api_gateway/
├── main.py        # ملف التطبيق الرئيسي
├── config.py      # إعدادات التكوين
├── routes.py      # تعريفات توجيه واجهة برمجة التطبيقات
├── auth.py        # منطق المصادقة
├── utils.py       # وظائف مساعدة
└── requirements.txt # تبعيات المشروع

مثال على الكود: main.py

from fastapi import FastAPI, Depends, HTTPException, Request
from fastapi.responses import JSONResponse
import uvicorn
import requests
import jwt
from config import settings
from auth import verify_jwt
from routes import router

app = FastAPI()
app.include_router(router)

@app.middleware("http")
async def add_process_time_header(request: Request, call_next):
    response = await call_next(request)
    return response

if __name__ == "__main__":
 uvicorn.run(app, host="0.0.0.0", port=8000)

مثال على الكود: routes.py

from fastapi import APIRouter, Depends, HTTPException, Request
from fastapi.responses import JSONResponse
import requests
import jwt
from config import settings
from auth import verify_jwt

router = APIRouter()

@router.get("/products/{product_id}")
async def get_product(product_id: int, request: Request, is_authenticated: bool = Depends(verify_jwt)):
  # إعادة توجيه الطلب إلى خدمة المنتج
  product_service_url = f"{settings.product_service_url}/products/{product_id}"

  try:
      response = requests.get(product_service_url)
      response.raise_for_status()  # إطلاق خطأ HTTP للاستجابات السيئة (4xx أو 5xx)
      return response.json()
  except requests.exceptions.RequestException as e:
      raise HTTPException(status_code=500, detail=f"Error communicating with product service: {e}")

@router.post("/orders")
async def create_order(request: Request, is_authenticated: bool = Depends(verify_jwt)):
 # إعادة توجيه الطلب إلى خدمة الطلبات
 order_service_url = f"{settings.order_service_url}/orders"
 body = await request.json()

 try:
  response = requests.post(order_service_url, json=body)
  response.raise_for_status()
  return response.json()
 except requests.exceptions.RequestException as e:
  raise HTTPException(status_code=500, detail=f"Error communicating with order service: {e}")

مثال على الكود: auth.py

from fastapi import HTTPException, Depends, Header
import jwt
from config import settings
from typing import Optional

async def verify_jwt(authorization: Optional[str] = Header(None)) -> bool:
 if not authorization:
  raise HTTPException(status_code=401, detail="Authorization header is required")

 try:
  token = authorization.split(" ")[1]
  jwt.decode(token, settings.jwt_secret, algorithms=[settings.jwt_algorithm])
  return True
 except jwt.ExpiredSignatureError:
  raise HTTPException(status_code=401, detail="Token has expired")
 except jwt.InvalidTokenError:
  raise HTTPException(status_code=401, detail="Invalid token")

مثال على الكود: config.py

import os
from typing import Optional
from pydantic import BaseSettings

class Settings(BaseSettings):
 product_service_url: str = os.getenv("PRODUCT_SERVICE_URL", "http://localhost:8001")
 order_service_url: str = os.getenv("ORDER_SERVICE_URL", "http://localhost:8002")
 jwt_secret: str = os.getenv("JWT_SECRET", "secret")
 jwt_algorithm: str = os.getenv("JWT_ALGORITHM", "HS256")

 settings = Settings()

التكوين

خزّن إعدادات التكوين، مثل عناوين URL لخدمات الواجهة الخلفية ومفاتيح المصادقة، في ملف تكوين منفصل (مثل `config.py`). استخدم متغيرات البيئة لتكوين بيئات مختلفة (التطوير، الاختبار، الإنتاج).

المصادقة

نفّذ المصادقة باستخدام JWTs. تتحقق بوابة API من JWT قبل إعادة توجيه الطلب إلى خدمة الواجهة الخلفية. يعزز هذا النهج الأمان واللامركزية. بالنسبة للمؤسسات الكبيرة، فكر في التكامل مع مزود هوية مثل Keycloak أو Azure AD. يمكن أن يؤدي ذلك إلى مركزية سياسات المصادقة والتفويض.

التوجيه

عرّف المسارات في ملف منفصل (مثل `routes.py`). استخدم وظيفة الموجه (router) في FastAPI لربط الطلبات الواردة بخدمات الواجهة الخلفية المناسبة. نفّذ التوجيه بناءً على مسار الطلب وطريقة HTTP والترويسات.

مثال: استخدام Docker لبوابة API

أنشئ `Dockerfile` لحزم بوابة API في حاوية.

FROM python:3.9-slim-buster

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

تكامل شبكة الخدمات

يؤدي دمج بوابة API بايثون مع شبكة خدمات مثل Istio إلى تعزيز الأمان والمراقبة وإدارة حركة المرور. سنركز على كيفية تكوين Istio لإدارة حركة المرور التي تتدفق عبر بوابة API.

تثبيت Istio

قبل المتابعة، تأكد من تثبيت Istio في مجموعة Kubernetes الخاصة بك. ارجع إلى وثائق Istio الرسمية للحصول على إرشادات التثبيت. يقدم العديد من مزودي الخدمات السحابية مثل AWS و Google Cloud و Azure خدمات Istio مُدارة تبسط النشر والإدارة.

حقن الحاوية الجانبية (Sidecar)

يستخدم Istio وكيلًا جانبيًا (Envoy) لاعتراض كل حركة المرور من وإلى الخدمة. لتمكين Istio لبوابة API، تحتاج إلى حقن الوكيل الجانبي في pod بوابة API. يتم ذلك عادةً عن طريق إضافة تعليق توضيحي إلى نشر الـ pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway
  labels:
    app: api-gateway
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api-gateway
  template:
    metadata:
      labels:
        app: api-gateway
      annotations:
        sidecar.istio.io/inject: "true" # تمكين حقن حاوية إستيو الجانبية (sidecar)
    spec:
      containers:
      - name: api-gateway
        image: your-api-gateway-image:latest
        ports:
        - containerPort: 8000

الخدمات الافتراضية والبوابات

يستخدم Istio الخدمات الافتراضية (Virtual Services) والبوابات (Gateways) لإدارة توجيه حركة المرور. تحدد البوابة نقطة الدخول لحركة المرور إلى الشبكة، بينما تحدد الخدمة الافتراضية كيفية توجيه حركة المرور إلى الخدمات داخل الشبكة.

إنشاء بوابة Istio

عرّف بوابة Istio لكشف بوابة API لحركة المرور الخارجية.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: api-gateway-gateway
spec:
  selector:
    istio: ingressgateway # استخدام بوابة الدخول الافتراضية لإستيو
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*" # استبدل بنطاقك

إنشاء خدمة افتراضية

عرّف خدمة افتراضية لتوجيه حركة المرور من البوابة إلى خدمة بوابة API.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-gateway-virtualservice
spec:
  hosts:
  - "*" # استبدل بنطاقك
  gateways:
  - api-gateway-gateway
  http:
  - route:
    - destination:
        host: api-gateway # اسم الخدمة في Kubernetes
        port:
          number: 8000 # المنفذ الذي تستمع إليه بوابة API

إدارة حركة المرور مع Istio

يوفر Istio إمكانيات قوية لإدارة حركة المرور، مثل:

• موازنة التحميل: توزيع حركة المرور عبر مثيلات متعددة من الخدمة. يدعم Istio خوارزميات موازنة تحميل مختلفة، بما في ذلك التوزيع الدوري (round robin)، وأقل الاتصالات (least connections)، والتجزئة المتسقة (consistent hashing).
• تقسيم حركة المرور (النشر التدريجي - Canary Deployments): طرح إصدارات جديدة من الخدمة تدريجيًا عن طريق إرسال نسبة صغيرة من حركة المرور إلى الإصدار الجديد. يتيح لك ذلك اختبار الميزات الجديدة في الإنتاج دون التأثير على جميع المستخدمين.
• كسر الدائرة (Circuit Breaking): منع حالات الفشل المتتالية عن طريق إيقاف حركة المرور تلقائيًا إلى الخدمات غير الصحية.
• حقن الأخطاء (Fault Injection): حقن تأخيرات أو أخطاء في حركة المرور لاختبار مرونة تطبيقك.

مثال: النشر التدريجي (Canary Deployment) مع Istio

لإجراء نشر تدريجي، يمكنك تكوين Istio لإرسال نسبة صغيرة من حركة المرور (على سبيل المثال، 10%) إلى الإصدار الجديد من بوابة API.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-gateway-virtualservice
spec:
  hosts:
  - "*" # استبدل بنطاقك
  gateways:
  - api-gateway-gateway
  http:
  - route:
    - destination:
        host: api-gateway # الإصدار 1
        port:
          number: 8000
        weight: 90
    - destination:
        host: api-gateway-v2 # الإصدار 2 (كناري)
        port:
          number: 8000
        weight: 10

المراقبة (Observability)

تُعد المراقبة والتسجيل أمرين حاسمين لفهم أداء وصحة بوابة API وخدمات الواجهة الخلفية. نفّذ مراقبة شاملة باستخدام أدوات مثل:

• Prometheus: نظام مراقبة لجمع وتخزين المقاييس. يتكامل Istio مع Prometheus لتوفير مقاييس حول حركة مرور الخدمة وزمن الوصول والأخطاء.
• Grafana: أداة لتصور البيانات لإنشاء لوحات معلومات لمراقبة تطبيقك.
• Jaeger: نظام تتبع موزع لتتبع الطلبات أثناء تدفقها عبر خدماتك المصغرة. يمكن لـ Istio إنشاء تتبعات تلقائيًا لجميع الاتصالات بين الخدمات.
• Fluentd/Elasticsearch/Kibana (EFK Stack): حزمة تسجيل لجمع السجلات وتخزينها وتحليلها.

القياس عن بعد (Telemetry) في Istio

يجمع Istio تلقائيًا بيانات القياس عن بعد حول حركة مرور الخدمة، بما في ذلك المقاييس والسجلات والتتبعات. يمكنك استخدام هذه البيانات لمراقبة أداء وصحة بوابة API وخدمات الواجهة الخلفية. قم بتكوين Istio لتصدير بيانات القياس عن بعد إلى Prometheus و Grafana و Jaeger.

مقاييس خاصة ببوابة API

بالإضافة إلى بيانات القياس عن بعد من Istio، يجب عليك أيضًا جمع مقاييس خاصة ببوابة API، مثل:

• معدل الطلبات: عدد الطلبات في الثانية.
• زمن الاستجابة: متوسط الوقت الذي يستغرقه معالجة الطلب.
• معدل الخطأ: النسبة المئوية للطلبات التي تؤدي إلى خطأ.
• معدل نجاح/فشل المصادقة: عدد محاولات المصادقة الناجحة والفاشلة.
• معدل إصابة ذاكرة التخزين المؤقت (Cache Hit Rate): النسبة المئوية للطلبات التي يتم خدمتها من ذاكرة التخزين المؤقت.

اعتبارات أمنية

الأمان أمر بالغ الأهمية عند بناء بوابة API. ضع في اعتبارك التدابير الأمنية التالية:

• المصادقة والتفويض: نفّذ آليات مصادقة وتفويض قوية لحماية خدمات الواجهة الخلفية الخاصة بك. استخدم JWTs أو OAuth 2.0 أو بروتوكولات أخرى متوافقة مع معايير الصناعة.
• التحقق من صحة الإدخال: تحقق من صحة جميع الطلبات الواردة لمنع هجمات الحقن (injection attacks).
• تحديد المعدل (Rate Limiting): نفّذ تحديد المعدل لمنع إساءة الاستخدام وهجمات الحرمان من الخدمة (denial-of-service).
• تشفير TLS: شفر جميع الاتصالات بين بوابة API وخدمات الواجهة الخلفية باستخدام TLS. يوفر Istio تشفير TLS تلقائيًا باستخدام TLS المتبادل (mTLS).
• جدار حماية تطبيقات الويب (WAF): استخدم WAF للحماية من هجمات تطبيقات الويب الشائعة، مثل حقن SQL والبرمجة النصية عبر المواقع (XSS).
• عمليات تدقيق أمنية منتظمة: قم بإجراء عمليات تدقيق أمنية منتظمة لتحديد ومعالجة نقاط الضعف.

TLS المتبادل (mTLS) مع Istio

يمكن لـ Istio فرض mTLS تلقائيًا على جميع الاتصالات بين الخدمات، مما يضمن تشفير ومصادقة جميع الاتصالات. يوفر هذا طبقة قوية من الأمان ضد التنصت والعبث.

مواضيع متقدمة

بوابة GraphQL

بدلاً من واجهات برمجة التطبيقات REST، فكر في استخدام GraphQL لجلب البيانات بشكل أكثر كفاءة. نفّذ بوابة GraphQL باستخدام مكتبات مثل Graphene و Ariadne. يسمح GraphQL للعملاء بطلب البيانات التي يحتاجونها فقط، مما يقلل من الجلب الزائد ويحسن الأداء.

بوابة gRPC

للاتصال عالي الأداء بين الخدمات، فكر في استخدام gRPC. نفّذ بوابة gRPC لكشف خدمات gRPC للعملاء الخارجيين. استخدم أدوات مثل grpc-gateway لإنشاء واجهات برمجة تطبيقات RESTful من تعريفات gRPC.

بوابة API بدون خادم (Serverless)

انشر بوابة API الخاصة بك كوظيفة بدون خادم باستخدام منصات مثل AWS Lambda أو Google Cloud Functions أو Azure Functions. توفر بوابات API بدون خادم قابلية للتطوير وفعالية من حيث التكلفة وتقليل النفقات التشغيلية. على سبيل المثال، يمكن دمج بوابة API مع وظائف AWS Lambda المكتوبة بلغة بايثون لمعالجة الطلبات. يمكن أن يقلل هذا النهج بدون خادم من تكاليف البنية التحتية بشكل كبير.

الخاتمة

يوفر بناء بوابة API بايثون مع تكامل شبكة الخدمات حلاً قويًا وقابلاً للتطوير لإدارة اتصال الخدمات المصغرة. من خلال الجمع بين نقاط القوة في بوابات API وشبكات الخدمات، يمكنك تحقيق أمان ومراقبة وإدارة حركة مرور محسّنة. هذه البنية المعمارية مناسبة تمامًا للتطبيقات الحديثة والسحابية الأصلية التي تتطلب توفرًا عاليًا وقابلية للتطوير وأمانًا. تذكر أن تأخذ في الاعتبار متطلباتك المحددة وأن تختار الأدوات والتقنيات التي تناسب احتياجاتك على أفضل وجه. على سبيل المثال، قد تفضل شركة أصغر Kong كبوابة API و Linkerd كشبكة خدمات نظرًا لسهولة استخدامهما نسبيًا، بينما قد تختار مؤسسة أكبر Istio وبوابة API بايثون مبنية خصيصًا للتحكم الدقيق في كل جانب من جوانب بنيتها المعمارية. إن اختيار الأدوات المناسبة والتنفيذ الدقيق للاعتبارات الأمنية المذكورة أعلاه أمر بالغ الأهمية للنجاح. علاوة على ذلك، تعد المراقبة والتكيف المستمران أمرًا حاسمًا للحفاظ على بوابة API قوية وآمنة في المشهد التكنولوجي المتطور باستمرار.